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PREFACE 

This System Design Guide is intended to aid a system de- 
sign engineer in implementing an ISDN Basic Rate Interface 
(BRI) Terminal Equipment (TE) application. The Design 
Guide is divided into the following sections: 

1.0 ISDN Basic Rate Interface Overview 

2.0 ISDN BRI Terminal Equipment Functional 
Requirements 

3.0 ISDN BRI Terminal Equipment Design Solution 

4.0 Summary 
Section 1 is intended to introduce ISDN BRI and to give 
some justification for implementing such an application. 
Section 2 presents the necessary hardware and software 
functional subsystems, without getting into specific imple- 
mentation details. Section 3 presents a design solution for 
the ISDN BR! application, introducing the National Semicon- 
ductor HPG16400E Microcontroller along with the Telenet- 
works ISDN software packages. Section 4 summarizes the 
ideas presented in this System Design Guide. 
References for this System Design Guide are found in Ap- 
pendix A. 

For more information regarding ISDN BRI implementations 
contact your local National Semiconductor representative or 
contact Telenetworks at (707) 778-6500. 

1.0 ISDN BASIC RATE INTERFACE OVERVIEW 

The Integrated Services Digital Network (ISDN) Basic Rate 
Interface (BRI) provides a replacement for the current sub- 
scriber line interface offering into businesses and homes. 
As shown in Figure 1, the ISDN BRI offering uses the same 
copper pair as the current conventional phones, but pro- 
vides more and better services to the subscriber. To har- 
ness these services it is necessary to follow the prescribed 
layered protocols for developing ISDN BRI Terminal Equip- 
ment (TE). This System Design Guide functionally defines 
these protocols and proposes an implementation solution 
for a particular ISDN BRI terminal design. This section de- 
fines what ISDN BRI services are and why they are worth 
the investment in a new technology. 
The INTEGRATED part of ISDN is apparent in two domains: 
the integration of voice and data on the same interface, and 
the integration of an out-of-band signaling (D) channel with 
the bearer (B) channels. The advantages of this integration 
are defined in the following paragraphs. 
The SERVICES part of ISDN are the main reason for ISDN's 
potential growth and acceptance in the future. Basic Voice 
and Basic Data services, and even the "Big 4" Supplemen- 
tary Services (HOLD/RETRIEVE, CONFERENCE, DROP, 
and TRANSFER), are not enough to propagate the ISDN 
cause. All of these services are available with the current 
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analog Centrex service offerings. For ISDN to be truly suc- 
cessful, cost-effective end-user applications must be devel- 
oped and supported that require the extended services that 
are only available through ISDN, e.g.. Keyset services, User- 
to-User data, and telemetry services on the D channel. 

The DIGITAL part of ISDN provides three digital channels 
(B1, B2 and D) between the Customer Premise Equipment 
(CPE) terminals and the Central Office. Any combination of 
voice and/or data services can be provided on either of the 
two bearer channels, while both signaling and data can be 
sent over the D channel. For example, two voice circuits can 
be implemented over the same wire pair that previously only 
supported one. Data can be sent at up to 64 kbits/ second, 
rather than the current nominal rate of 2400 baud using a 
modem. End-to-end digitized information is less susceptible 
to noise, allowing for clearer voice quality and less data 
retransmissions. Several data links running at sub-rates 
(less than 64 kbits/second) can be multiplexed onto a B 
channel or the D channel using various time division multi- 
plexing techniques not available in the analog domain, thus 
taking full advantage of the channel bandwidth. 
The NETWORK part of ISDN includes marketing and tariff- 
ing issues. For ISDN to be successful digital facilities must 
be available from end-to-end, i.e., no isolated ISDN islands. 
The network must provide signaling and bearer services 
throughout the country (and eventually the world), using Sig- 
naling System #7 as the inter-office backbone. The network 
is also responsible for the appropriate billing mechanisms 
for the ISDN services. User-driven applications must be de- 
veloped and supported by the network, along with a cost-ef- 
fective tariffing structure. 

BRI ISDN will slowly become available to the general public. 
It is currently being deployed in large metropolitan areas, 
targeted for business environments. Just when more gener- 
al deployment will occur depends on the rate of deprecia- 
tion of current equipment, tariffing rates for the ISDN serv- 
ices, and user acceptance of the new ISDN technology. 
End-users are just now becoming educated on the virtues of 
ISDN. Ultimately, the end-users will have to drive OEM ven- 
dors to provide ISDN terminal equipment that brings special 
services to them. These services will have to either cost 
less than currently available services, or be value-added 
and cost effective. The remainder of this document provides 
OEM vendors with an idea of what is involved in designing 
an ISDN BRI terminal, and what "building blocks" are avail- 
able for implementing such a terminal. 
There are several types of ISDN Terminal Equipment (TE). 
TEs can be Voice and/or Data; PC-based or stand-alone; 
synchronous and/or asynchronous; OB-I-D, 1B-I-D, or 
2B + D; X.25, V.I 20, or V.110, or any combination of data 
protocol support. Figure 1 shows a generic stand-alone 
voice/data terminal configuration. 
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FIGURE 1 



2.0 ISDN BRI TERMINAL EQUIPMENT 
FUNCTIONAL REQUIREMENTS 

The ISDN BRI Terminal Equipment (IE) Functional Require- 
ments are layered, in accordance with the OSI Layered 
Model. ISDN applications include requirements at the Physi- 
cal Layer, the Data Link Layer, the Network Layer and the 
Application Layer. Figure 2 reflects these layered functions 
for each of the following subsystems: the Digital Subscriber 
Signaling System #1 (DSS1) protocol requirements, the 
data protocol termination requirements, and the Mainte- 
nance and Management requirements. 
Several types of data protocols exist today (e.g., X.25, 
V.120, V.110, DMI, and T-Link). This System Design Guide 
focuses on the requirements necessary to design an ISDN 
BRI voice/data terminal, using the X.25 asynchronous and 
synchronous data protocol for terminal adaptation. The defi- 
nition of the layered requirements for the other foremen- 
tioned data protocols is beyond the scope of this Design 
Guide. The X.25 data protocol was chosen because it is the 
most prevalent data protocol today, as well as the best de- 
fined protocol. The requirements for transporting X.25 data 
on an ISDN BRI terminal are defined as part of this paper 
and are more generally defined in CCITT Recommendation 
X.31. 

2.1 System-Level Requirements 

A relatively powerful CPU engine is necessary to process 
the DSS1 and data communication protocols. Small 8-bit 
microcontrollers are not generally adequate for the task. On 
the order of 128 kbytes of ROM are necessary to implement 
these CCITT protocol requirements, assuming the code is 
compiled from a high-level language such as "C". 
Careful consideration must be given to controlling an ISDN 
BRI application. There are several asynchronous, detailed 
processes going on that require some level of coordination 
regarding process scheduling, buffer management, mes- 
sage passing, and timer handling. Selection of an adequate 
design environment in which to nest the various processes 
is of utmost importance. Use of a multitasking executive is 
recommended. 

2.2 Physical Layer Requirements 

To make a terminal a member of the ISDN passive "S" 
Interface bus a front end "S" interface device is necessary. 
This device must allow for D channel contention and under- 
stand the framing channel. Such a device will take varying 
degrees of software intervention and control, depending on 
the device architecture. The 1.430 activation (and optionally 
deactivation) sequence must be followed to initialize the 
"S" interface device of an ISDN BRI terminal. 
For a voice application, a CODEC is needed to convert ana- 
log voice into digital PCM. A keypad and hookswitch, along 
with a display, are also required. Some software intervention 
is necessary to activate and deactivate these devices, de- 
bounce hardware inputs, and control these devices. A call 
progress tone generator is also required to "play" progress 
tones (e.g., DIALTONE, BUSY, and RINGBACK) to the ear. 
A set of telephony device driver modules must be available 
to interface to these hardware devices. 
For data applications, hardware and software drivers are 
needed to control the R interface devices. For asynchro- 
nous data applications a UART is required, along with a 
UART Software Driver module to control the interface. For 



synchronous data applications a USART is required, along 
with an HDLC Software Driver module to control the inter- 
face. 

In some applications it is not desirable to hard-wire a partic- 
ular bearer channel to the CODEC or to the HDLC port. In 
these cases it may be necessary to provide a switching de- 
vice to dynamically switch a bearer channel to either of the 
two sources. 

Semiconductor vendors have developed several types of 
internal digital formats that allow these various devices to 
communicate. Serial decoding is the physical layer function 
that presents the S interface data to the particular devices. 
Care must be taken to ensure that the selected Layer 1 
devices all provide the appropriate digital format. 

2.3 Link Layer Requirements 

The OSI Link Layer (2) is defined by two sets of procedures: 
High-Level Data Link Control (HDLC) procedures and Link 
Access Procedures (LAP). HDLC procedures are typically 
done in hardware with synchronous channel controllers. 
Link Access Procedures are typically done in software, al- 
though some silicon devices do offer limited LAP functionali- 
ty- 

As shown in Figure 2, two HDLC Controllers are required: 
one to terminate the D Channel and one to terminate one of 
the Bearer Channels for data. HDLC software device drivers 
are needed to control both of these HDLC channels. From a 
software implementation point of view, DMA controlled 
HDLC channels are much more desirable than FIFO-based 
channels because they ease the CPU interaction require- 
ments. 

The D Channel termination at Layer 2 requires implementa- 
tion of the Line Access Procedures of CCITT Recommenda- 
tion 0.921 , more commonly referred to as LAPD. LAPD pro- 
vides in-sequence, error-free transmission of frames to the 
higher layers. LAPD can handle multiple logical links. For 
the ISDN BRI there are at least three logical links, one for 
signaling functions (SAPI = 0, TEI = X), one for mainte- 
nance functions (SAPI = 63, TEI = 127), and one for D 
channel data (SAPI = 16, TEI = Y). "X" and "Y" are arbi- 
trary, but valid, TEI assignment values. 
The X.25 B Channel data termination at Layer 2 requires 
implementation of the Link Access Procedures of CCITT 
Recommendation X.25, more commonly referred to as 
LAPB. Like LAPD, LAPB also provides in-sequence, error- 
free frames to the higher layers. LAPB can only handle one 
logical link at Layer 2. 

2.4 Network Layer Requirements 

The ISDN DSS1 D Channel signaling termination at Layer 3 
requires implementation of the Protocol Control procedures 
of CCITT Recommendation 0.931. These procedures in- 
clude setting up and tearing down local access connections 
between the terminal and the Central Office. These connec- 
tions can be for voice or data services and can be request- 
ed for the BRI B or D channels. 

For X.25 data calls all packets must be processed by the 
Layer 3 Packet Layer Process (PLP). These procedures in- 
clude setting up and tearing down virtual packet switch con- 
nections between end-to-end X.25 terminals. These virtual 
connections are established "in-band" during the X.25 call 
setup phase. 
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2.5 Application Layer Requirements 

As mentioned above, for the sake of this System Design 
Guide a hypothetical stand-alone ISDN voice/data terminal 
(TE) will be defined that allows voice or data services on 
either of the two bearer (B) channels. It will support synchro- 
nous and asynchronous X.25 data connections on either 
bearer channel, and asynchronous data on the D signaling 
channel. 

A Basic Rate Interface Application Controller is required 
that includes the Call Control procedures of Q.931 and X.31 . 
This controller keeps track of which protocol is on which 
channel. It must also interface to the I/O device drivers for 
the asynchronous and synchronous terminals, as well as 
the voice-related telephony hardware. 
For the X.25 asynchronous data application the TE expects 
a data application to be running on a PC connected via the 
"R" interface, a local UART. The TE intercepts commands 
across the "R" interface and translates them into DSS1 
Setup and Teardown commands. Service can be requested 
for either the B or D channel. Once a channel is setup, then 
the data phase (packet transfer) is established with the X.25 
PLP. When data transfer is complete the PC Application will 
disconnect with a particular command which will be translat- 
ed into a DSS1 release sequence, at which time the channel 
will be available for another service. 

For the X.25 synchronous data application a synchronous 
X.25 DTE is expected at the other side of the "R" interface. 
A USART is required with a special HDLC device driver 
module to terminate the 56 kbit/second data stream. The 
driver initially monitors the link for a link establishment indi- 
cation (SABM). If the DTE requests service first, (link estab- 
lishment indication is sent by the DTE), an ISDN bearer 
channel is requested via the DSS1 protocol on the D chan- 
nel. If the network requests service first the network will 
setup the bearer channel using the DSS1 protocol, and then 
establish the data link in-band with the DTE. After success- 
ful setup of a B channel, packets are sent between the DTE 
and the packet handler. At the end of the data session the 
network side is expected to disconnect the data link in-band 
(with a Layer 2 DISC command) and then release the call 
using DSS1 release procedures. 

Voice service is controlled entirely within the TE. During the 
time that synchronous data service is being provided on one 
of the B channels, it is recommended that the TE only allow 
asynchronous data service on the D channel to avoid voice 
service from being blocked. In a passive bus arrangement, 
i.e., multiple TEs on the same S interface, it is recommend- 
ed that asynchronous data service only be allowed on the D 
channel. Of course this is a decision that must be made, 
and enforced, at the application layer. 

2.6 Maintenance and Management Requirements 

Every application of this magnitude requires some degree of 
maintenance and management. Some maintenance func- 
tionality is required by the Network, while some of the func- 
tionality is strictly application dependent. The major mainte- 
nance functions include provisioning the TE, statistic collec- 
tion and reporting, physical layer alarm reporting and recov- 
ery, protocol breakdown recovery, and resource depletion 
handling. Other peripheral maintenance functions include 
loopback mechanisms, human interface capability, and soft- 
ware PROM revision maintenance. 



Procedures from 1.430 are necessary to activate and option- 
ally deactivate terminals on the "S" Interface. Procedures 
for TEI assignment are defined in CCITT Recommendation 
0.921 , and in the AT&T and NTI switch specifications. Pa- 
rameter negotiation procedures are also defined in these 
switch specifications. For any BRI implementation, exten- 
sions must be made to the Maintenance and Management 
functions beyond what is defined in specifications. 
It is generally prudent to introduce a UART-based mainte- 
nance interface into a design of this complexity. This inter- 
face allows for message tracing, limited process interaction, 
and optional program download and debug capability all 
from a PC or terminal attached to the UART. A maintenance 
interface software driver module is needed to manage the 
screen output and keyboard input functions for the terminal 
attached to the UART. This interface can be shared with the 
asynchronous data application, only being available when 
the data application is not operating. 

3.0 ISDN BRI TERMINAL EQUIPMENT 
DESIGN SOLUTION 

Figure 3 presents an implementation solution for the ISDN 
BRI Terminal Equipment (TE) requirements. The solution re- 
volves around the National Semiconductor HPC16400E Mi- 
crocontroller and the Telenetworks ISDN Software pack- 
ages. 
Hardware Solution 

• NSC HPC16400E 

Powerful 16-Bit Microcontroller: 

2 Onboard HDLC/DMA Controllers 

1 Onboard UART 

4 Onboard Timers 

Synchronous Serial Time-Slot Decoder 

General Purpose I/O Ports 

8 Prioritized Interrupt Levels 

MICROWIRE® Interface 

• NSC TP3420 S Interface Device (SID) 

• NSC TP3076 COMBOTM Codec 

• USART 
Software Solution 

Telenetworks ISDN Software Off-the-Shelf Packages 

MTEX Multitasking Executive 

1.430 BRI Layer 1 Driver 

HPC16400E Dual HDLC/DMA Driver 

Layer 2 Task 

Layer 3 0.931 Task 

X.25 Packet Layer Process Task 

Prototype X.31/0.931 Call Control Task 

Basic Management Entity Task 

HPC16400E UART Driver 
Custom Software Development (by Telenetworks or OEM) 

USART HDLC Driver 

Application Specific X.31 /Q.931 Call Control Task 

Command Translator/PAD Task 

Extended Management Entity Task 

Extended Applications for Supplementary Services 

Telephony Device Drivers 
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FIGURE 3 



3.1 System-Level Solution 

The NSC HPC16400E is a powerful 16-bit CPU engine ttiat 
is fully capable of processing the DSS1 and B-Channel data 
communication protocols. The HPC16400E has two flexible 
onboard HDLC/DMA controller channels that are Ideal for 
terminating the D Channel and data on a B channel. It has 
an onboard UART to terminate the asynchronous data inter- 
face, 4 onboard timers, and several general purpose I/O 
pins. The HPC16400E can address 544 kbytes of memory 
space, however for the ISDN BRI application the entire 
memory space should be less than 128 kbytes. 
An off-the-shelf Multitasking Executive, MTEX, that was de- 
signed specifically for controlling ISDN BRI terminal applica- 
tions has been hosted on the HPC16400E. MTEX has the 
following subsystems: 

Task Scheduler 

Mall Manager 

Timer Handler 

Memory Manager. 
MTEX was designed to provide an environment for commu- 
nication protocol applications, with special built-in features 
to handle timers and flow control. Processes, such as Layer 
2 Link Access Procedures and Layer 3 protocols, are de- 
signed as tasks running under MTEX. Intertask messaging 
is via the MTEX Mall utilities. MTEX also provides memory 
management utilities for buffer management. 

3.2 Physical Layer Solution 

The National Semiconductor "S" Interface Device (SID- 
TP3420) terminates the "S" Interface at the physical layer. 
The off-the-shelf 1.430 BRI Layer 1 software driver module 
is available to control the SID as defined by CCITT recom- 
mendation 1.430. The SID also has a built-in mechanism for 
"switching" the bearer channels upon command. The SID 
communicates with the NSC I-IPC16400E via NSC's Ml- 
CROWIRE interface. The MICROWIRE interface is a three- 
wire serial Interface (SI, SO, and CLK). 
The NSC COMBO Codec, TP3076 can be used for terminat- 
ing the voice path in the TE and converts to analog voice 
signals. The COMBO communicates via the MICROWIRE 
interface. 

The HPC16400E onboard UART Is Ideal for the asynchro- 
nous data interface and for the maintenance interface. The 
UART has a high resolution clock for rates up to 19.2 kbaud. 
An off-the-shelf HPC16400E UART software driver module 
is available that interfaces to this UART. This driver fields 
messages from tasks and outputs them to the UART, as 
well as receiving input from the UART and sending it to the 
appropriate task. 

A synchronous communication device is needed to termi- 
nate the synchronous data interface. NSC makes a stand- 
alone USART for just this purpose, the TP3460. A special 
USART HDLC software driver module is needed to control 
the USART and monitor the interface for particular com- 
mands. The requirements for this driver are defined below in 
the synchronous data application section of this document. 

Custom Layer 1 Telephony drivers and routines are needed 
to control such things as hookswitch, keypad Input, LCD or 
LED updates, local tone generation, power ringing, and vari- 
ous other application dependent telephony device require- 
ments. 

The HPC16400E has a programmable onboard Serial Time- 
Slot Decoder that provides an interface to the B and D 
channels of several popular chip-to-chip Interface formats. 



3.3 Link Layer Solution 

The HPC16400E has two independent HDLC/DMA control- 
ler channels Integrated onboard with the Central Processing 
Unit. For ISDN BRI applications, one channel runs at 
16 kbits/second for the D Channel, the other runs at 
64 kbits/second for data on a B Channel. The DMA Control- 
lers receive and transmit entire frames prior to interrupting 
the processor. This allows for a much simpler Layer 2 Driver 
design than would a FIFO-based HDLC controller. The 
HPC16400E has several other features which ease the im- 
plementation of the ISDN BRI application. These features 
are defined in the following paragraphs. 
The HPC16400E can operate in a special split field mode 
where the Layer 2 Header data Is placed in one buffer, while 
the following Layer 3 Information data is placed In another 
buffer. This feature eases the memory management require- 
ments of an application and decreases the need for copying 
messages from buffer to buffer. 

If the split field feature is not used then HPC16400E DMA 
chaining features can be fully exploited to simplify the appli- 
cation design. On the receive side, four buffers can be made 
available for incoming frames. When a frame arrives, an in- 
terrupt is generated by the DMA Controller. While the proc- 
essor is responding to the interrupt and fielding the current 
message, new frames that arrive will automatically be 
placed Into memory buffers. Up to 4 messages can arrive 
without any processor intervention. On the transmit side two 
messages can be output, delimited by a closing/opening 
flag, without processor intervention. If the split field feature 
described above is used then two frames can be chained on 
the receive side, with no chaining available on the transmit 
side. 

The HPC16400E can be programmed to recognize particu- 
lar Layer 2 addresses (SAPI-TEI combinations). This feature 
is useful if the terminal Is to be used in a passive bus ar- 
rangement. In such an arrangement messages not intended 
for a particular terminal on the bus can be filtered by the 
terminal and discarded without any processor intervention. 
The two HDLC/DMA channels are controlled by an off-the- 
shelf HPC16400E Dual HDLC/DMA software driver module. 
The driver consists of an Interrupt Service Routine, and two 
Service Request Tasks, one for each channel. The driver is 
responsible for initializing the synchronous channel hard- 
ware, and controlling the transmission and reception of 
frames. It is also required to handle buffer management for 
messages in both directions. Buffers must be allocated for 
incoming messages and deallocated after the transmission 
of outbound messages. One exception to this rule is that 
after transmission, I frame buffers are NOT deallocated by 
the Driver since they may need to be retransmitted if unac- 
knowledged. The Layer 2 Software Module has the respon- 
sibility for deallocating transmitted I frame buffers when the 
appropriate acknowledgement is received. This driver con- 
figures both HPC16400E HDLC/DMA channels to use the 
split field feature. 

The D Channel is terminated at Layer 2 with the off-the- 
shelf Layer 2 Software Task providing the LAPD solution. 
The LAPD was prototyped after the CCITT 1988 Blue Book 
version for 0.921, however it has been tailored to imple- 
ment the Layer 2 Specifications In the 5ESS 5E5 generic 
software release from AT&T, and the DMS100 BCS-28 ge- 
neric software release from Northern Telecom. LAPD logi- 
cal entitles are defined based on SAPI and TEI. 



The B Channel is also terminated at Layer 2 with the off-the- 
shelf Layer 2 Software Task providing the LAPS solution. 
The LAPB was prototyped after the CCITT 1 988 Blue Book 
version for X.25 Layer 2. 

3.4 Network Layer Solution 

The off-the-shelf Layer 3 Q.931 Task is designed to imple- 
ment the call setup and teardown protocols as defined in 
the CCITT Blue Book version for Q.931. The Layer 3 Task 
has also been tailored to implement both the Layer 3 Speci- 
fications in the 5ESS 5E5 generic software release from 
AT&T, and the DMS100 BCS-28 generic software release 
from Northern Telecom. This protocol terminates the D 
Channel at Layer 3. Network Link logical entities are defined 
based on Channel Endpoint Suffix (CES), Call Reference 
and Call ID. 

The off-the-shelf Layer 3 X.25 Packet Layer Processor 
(PLP) Task is designed to implement the establishment of 
X.25 virtual data connections. Layer 3 PLP logical entities 
are defined based on CES and Logical Channel Number. 

3.5 Application Layer Solution 

Applications by their very nature are proprietary, so very lit- 
tle can be offered "off-the-shelf". Certain functions have 
been "standardized" at the application layer, but in general 
custom code design and development is necessary. Supple- 
mentary Services are defined in both the voice and data 
domain, however the invocation of these services is very 
application dependent and requires custom solutions. 
Telenetworks does offer a prototype X.31 /Q.931 Call Con- 
trol module that controls voice calls over an ISDN interface, 
as well as asynchronous and synchronous X.25 data calls. 
For the voice application this module controls various te- 
lephony devices by communicating with the Telephony De- 
vice driver modules. It also expects to communicate with a 
Command Translator/ PAD Task and a USART/HDLC soft- 
ware driver module, as defined in the following paragraphs. 

3.5.1 Asynchronous Data Application 

For this specific X.25 asynchronous data application exam- 
ple the TE expects to communicate with a PC running the 
Hayes Modem application program. The Hayes Modem pro- 
gram communicates out of the PC UART toward a modem. 
The "expected" modem is replaced by the ISDN TE. A 
Command Translator/PAD Task will be needed to interpret 
the Hayes AT commands for setting up and tearing down 
the desired bearer service. 

If the PC user wants service, then a service request with a 
called party number arrives at the TE in a Hayes command 
and is translated into an ISDN Setup command. This data 
control message is sent to the X.31 /Q.931 Call Control 
Task. The DSS1 protocol then sets up the appropriate data 
service on either the D or a B channel. If the network side 
wants service then the network sets up an ISDN call using 
the DSS1 call setup procedures. In this case the appropriate 
data control response is sent from the Call Control Task to 
the Command Translator/PAD Task. 
Once the call setup sequence has reached the ACTIVE 
state then the data phase is entered, at which time the 
Command Translator/PAD Task acts like a Packet Assem- 
bler/Disassembler (PAD) and communicates directly with 
the X.25 PLP Task. In this example, data is rate adapted 
from a nominal 1200 baud rate at the UART to either the 
16 kbits/second D channel rate or the 64 kbits/second B 
channel rate. 

After the data session the call is cleared either by a Hayes 
command from the PC application or from the far end. In 



either case, the X.25 link is released, and then the ISDN 
facility is released using the DSS1 call clearing procedures. 

3.5.2 Synchronous Data Application 

For this X.25 synchronous data application example the TE 
expects to communicate with an X.25 Data Terminal Equip- 
ment (DTE) running synchronous 56 kbits/second data. A 
synchronous channel controller device (USART) terminates 
the "R" interface. A custom USART device driver module 
will be needed to control the USART and to monitor certain 
data control commands. 

When an X.25 DTE requests service it typically sends a Lay- 
er 2 LAPB SABM command to establish the data link. The 
USART HDLC driver module intercepts this SABM and 
sends a data control service request to the X.31 /Q.931 Call 
Control Task. This message prompts the Call Control Task 
to set up an ISDN bearer channel using the DSS1 call setup 
procedures. Qnce the call setup sequence has reached the 
ACTIVE state then the Call Control Task sends a message 
to the USART HDLC driver module that a bearer channel is 
available. The USART driver then sends the SABM directly 
to the HPC16400E HDLC driver module. The network side 
can also request service, in which case the Packet Handler 
sets up the ISDN bearer channel using the DSS1 call setup 
procedures. In this case the Call Control Task prompts the 
USART driver module that a bearer channel is available. 
In either of the above cases, DTE to DCE is established and 
the data phase is entered. During the data phase packets 
are transmitted directly from the USART driver to the 
HPC16400E dual HDLC driver without any intervention by 
the TE. In this example, data is rate adapted from the nomi- 
nal 56 kbits/second rate to the ISDN 64 kbits/second B 
channel rate. 

After the data session the network side is responsible for 
initiating the call clearing process by first disconnecting the 
X.25 data link with a LAPB Disconnect command. The net- 
work side then clears the ISDN facility with the DSSI call 
clearing procedures. The Call Control Task informs the 
USART driver module that the bearer channel has been re- 
leased. 

3.6 Maintenance and Management Solution 

Most of the Management Entity Task's functions are appli- 
cation dependent, such as provisioning the ISDN BRI termi- 
nal, collecting statistics from the various hardware devices, 
and alarm detection and recovery. These functions will re- 
quire custom code development. 

As previously mentioned a software driver is available that 
activates and optionally deactivates a BRI terminal. This 
driver works in concert with Layer 2, the Management Entity 
procedures, the particular application, and of course the 
NSC SID. 

The TEI Assignment procedures are also included in the 
Management Entity Task. Provisions have been made for 
both automatic and non-automatic TEI assignment proce- 
dures. TEI Check and Verify procedures are also included. 
Management functions such as parameter negotiation and 
higher layer processes are application dependent and re- 
quire custom solutions. 

The HPC16400E onboard UART can be used for the main- 
tenance interface. This interface is defined in the physical 
layer section of this document. The maintenance features 
would only be available when the asynchronous data serv- 
ices are not in progress. Additional commands must be add- 
ed to the PC application program to control the mainte- 
nance interface. 



3.7 Software Development Environment 

The process of developing a software application around 
the Telenetworks ISDN software will vary greatly depending 
on the application and the target hardware. The procedure 
given below is an example that might apply to the develop- 
ment of an ISDN BRI application. Task View, a testing tool 

developed by Telenetworks, is defined below, as well as the 
software tools that are available for the NSC HPC16400E. 
In a typical ISDN BRI application there are two main areas 
of software development. First, device drivers must be writ- 
ten for the particular telephony hardware that exists in the 
target system (e.g.. Layer 1 drivers and DMA/HDLC driv- 
ers). Second, a Call Control Application Task must be de- 
signed to control the telephony hardware and interface to 
the Layer 3 Protocol Control Tasks. 
Typically, in such a development process, the target hard- 
ware is not available at the time that software development 
begins. This suggests a three step software development 
process. First, the Call Control Application Task is written 
and is unit-tested in a PC environment. Second, when the 
target hardware becomes available, the telephony hardware 
drivers are written and unit-tested in this target environment. 
Finally, the entire system software is integrated and tested 
with the hardware. 

3.8 Task View Description 

To aid in testing ISDN software modules Telenetworks has 

developed Task View. Task View is a special-purpose 

debugging task that can be run, together with other tasks, 
under the MTEX Multitasking Executive. It reads and inter- 
prets a user-supplied ASCII file, containing a test scenario. 

Under control of the test scenario, Task View sends mail 

messages to a specified mailbox (or mailboxes), where they 
are read by the task(s) under test. Mail messages sent by 
the task(s) in response to this input are then displayed by 

Task View. In this way tasks can be debugged in isolation, 

before integration into the complete target environment. 
The full-featured Task View operates only in a PC environ- 
ment, since it uses the DOS file system to handle the test 
scenario files. This is less of a limitation than it might ap- 
pear, since many tasks interact only with the MTEX Multi- 
tasking Executive and can be unit tested and debugged in a 
PC environment, running under the PC version of MTEX, 
before integration with other tasks in the target environ- 
ment. However, some modules, in particular I/O drivers, can 
only be tested in the target hardware environment. A simpli- 
fied version of Task View has been ported into the embed- 
ded HPC environment for testing of the I/O Drivers. Task 

View has also been ported into the Sun workstation devel- 
opment environment. 



3.9 NSC Development Tools 

Below is a list of the development tools available for the 
NSC HPC16400E. 

HPC "C" Compiler 

HPC Linker 

HPC PROM tools 

HPC Microcontroller On-Line Emulator (MOLEtm) 

NSC TP3500 ISDN Evaluation Target System. 

4.0SUI\/II\/IARY 

As ISDN BRI becomes more and more prevalent, users will 
require terminal vendors to provide new ISDN products or to 
implement ISDN interfaces into their current products. This 
System Design Guide has attempted to present a compre- 
hensive design solution for those vendors interested in de- 
signing an ISDN BRI product. NSC and Telenetworks are 
committed to providing ISDN solutions to the telecom indus- 
try. This Design Guide did not discuss implementation of the 
two public data protocols, V.120 and V.110. It also did not 
discuss implementation of any private data protocols such 
as DMI and T-Link. This was intentional in an effort to some- 
what scope the Design Guide. However both NSC and Tel- 
enetworks have developed design support for these proto- 
cols and others. NSC has just announced their "R" Inter- 
face Device, the TP3460, which provides many of the hard- 
ware sensitive functions of V.1 10. Certain V.1 10 and V.120 
software modules are available to also aid a designer in 
developing a terminal adapter for these protocols. 
For more information on ISDN BRI implementations contact 
your local National Semiconductor representative or contact 
Telenetworks at (707) 778-6500. 

APPENDIX A: REFERENCES 

5ESS ISDN Basic Rate Interface Specification, 5E5 Generic 
Program, AT&T Document 5D5-900-311, December 1987, 
Chapter III (Layer 2 and Management Entity) and Chapter IV 
(Layer 3). 

DMS-100 Basic Rate Interface Specification, Northern Tele- 
com Document NIS S208-4, October 1988, Section C (Lay- 
er 2 and Management Entity) and Section D (Layer 3 Func- 
tional Mode). 

CCITT Recommendations Q.921, 0.931, X.25, X.31, and 
1.430 "Blue Books", Geneva 1989. 
National Semiconductor HPC16400E Data Sheet 
National Semiconductor HPC16400E User's Manual. 
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LIFE SUPPORT POLICY 

NATIONAL'S PRODUCTS ARE NOT AUTHORIZED FOR USE AS CRITICAL COMPONENTS IN LIFE SUPPORT 
DEVICES OR SYSTEMS WITHOUT THE EXPRESS WRITTEN APPROVAL OF THE PRESIDENT OF NATIONAL 
SEMICONDUCTOR CORPORATION. As used herein; 

1. Life support devices or systems are devices or 2. A critical component is any component of a life 



systems which, (a) are intended for surgical implant 
into the body, or (b) support or sustain life, and whose 
failure to perform, when properly used in accordance 
with instructions for use provided in the labeling, can 
be reasonably expected to result in a significant injury 
to the user. 



support device or system whose failure to perform can 
be reasonably expected to cause the failure of the life 
support device or system, or to affect its safety or 
effectiveness. 
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